今天沙灘車太累ㄌ好想棄賽

透過這八堂課，也算是對分散式系統有一些初步認識，
之後再找時間接著看 Martin Kleppmann 的 Designing Data-Intensive Applications。
老實說畢竟還沒開始工作，並不清楚這些知識會怎麼樣幫助到未來，
但上課中了解到各種問題、並思考如何解決，還是非常過癮的事情～

第一章初步認識了什麼是分散的系統，分散式系統中節點們經常使用 RPC 來聯繫，
以及把大程式切成透過 RPC 互相交流的 micro services。

第二章提到兩個思想實驗：two generals 以及 byzantine generals 問題，分別代表網路與節點出狀況。接著為了方便未來討論，對 network / node / timing 建立模型。
並講解容錯（Fault tolerance）、高可用（high availability）的概念，
SPOF 表示一個節點出狀況（faulty）時，會導致整個系統爛掉（failure），
而用衡量可用性（availability）需使用 SLO(Service level objective) ，例如此 99.9%的請求都能在 200ms 內得到回覆。

第三章在講物理時間（Physical time），也就是以經過秒數來計算的時間，
即使用 NTP sync 都還是可能有誤差，如果依據物理時間，很可能發生時空旅行（例如訊息錯亂）
為了了解邏輯時間，需要先定義 happens before relation，這個關係需要兩個節點有訊息往來才能確認先後。Concurrent 的事件則是不能被比較的。
因果關係（Causality）來表示 A 事件可能導致 B，訊息或事件的順序常常需要符合 causality。如果訊息顯示「B：我還沒吃」才是「A：你吃晚餐了嗎？」，這樣違反 causality 的順序通常也不會是我們期望的結果。

第四章開始講邏輯時間（Logical time），也就是依據發生的事件數來計算的時間。
有了 Lamport clock，加上節點的 identifier（例如編號或取名），節點們就可以決定出一種符合 causality 的 total order 排序，total order 表示全部的節點都可以被排序而不是只有部分的。
Vector clock 是一組 timestamps，可以捕捉完整的 happens before relation。
反觀 lamport clock，就算 Lamport(e1) < Lamport(e2)，也只能知道要馬 e1 比 e2 早發生，要馬兩個事件是 concurrent 的。
再來介紹的廣播在分散式系統是很重要的一環，確保廣播訊息一定會送達（reliable）有很多方法，比較有效率的是節點們收到廣播訊息也傳給別人，讓廣播訊息像八卦或是病毒一樣傳遍整個系統（Gossip protocols）。
廣播演算法更重要的差別主要在於訊息「到達應用程式」（deliver）的順序：分為 FIFO / Casusal / Total order / FIFO total order broadcast。

第五章提到為了容錯、可用性、效能等理由，我們希望把一個節點的資料複製（replicate）到別的節點，這些節點稱為 replicas。在此介紹了幾個使用者互動而更新節點上的資料時，會發生的問題，分別可能要注意演算法是否設計成 idempotent、commutative 等。
而當 replicas 之間的資料不一致，會需要想辦法 anti-entropy：每個動作都附上邏輯 timestamps + 刪除時做標記（tombstone），這樣就能讓每個 replica 都保持到最新的紀錄。
多個 client 都想對同個數值做更新時，可以 last writer wins，依據 lamport clock 留下最後的更新；也可以使用 multi-value register，依據 vector clock，能夠對 concurrent 的事件（稱為 siblings 或 conficts）做處理。

開始越來越複雜（？但人在外面先不打了，明天回台北

小總結打到第五章，其他回台北再說